A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present application relates generally to cryptographic systems and, more particularly, to methods for creating and managing server-based certificate (key) crypto policy in such systems.
With each passing day, more and more computers are connected together through pervasive open networks, such as the Internet, Wide Area Networks (WANs), and the like. With the ever-increasing popularity of such environments comes the need for exchanging messages and other documents in a secured fashion over an open communication network. To this end, some sort of cryptographic system is usually employed.
Generally, cryptographic systems use either xe2x80x9csecret-keyxe2x80x9d encryption or xe2x80x9cpublic keyxe2x80x9d encryption. In xe2x80x9csecret-keyxe2x80x9d encryption, a single key is used for both encryption and decryption. Consider, for example, a user (sender) who wants to send an e-mail message to a colleague (recipient) in a secured manner, such that no one who intercepts the message will be able to read it. If the sender employs a cryptographic xe2x80x9csecret keyxe2x80x9d to encrypt the message, the recipient, in turn, must also use the same key to decipher or decrypt the message. As a result, the same key must be initially transmitted via secure channels so that both parties can know it before encrypted messages can be sent over insecure channels. This is typically inconvenient, however. A better approach is, therefore, sought.
Public key cryptography overcomes the problem by eliminating the need for a single xe2x80x9csecretxe2x80x9d key. As illustrated in FIG. 1A, each user of a public key cryptographic system has two mathematically-related keys, a xe2x80x9cpublic keyxe2x80x9d and a secret or xe2x80x9cprivate key.xe2x80x9d Operating in a complementary fashion, each key in the pair unlocks the code that the other key makes. Knowing the public key does not help deduce the corresponding private key, however. Accordingly, the public key can be published and widely disseminated across a communications network, such as the Internet, without in any way compromising the integrity of the private key. Anyone can use a recipient""s public key to encrypt a message to that person, with the recipient, in turn, using his or her own corresponding private key to decrypt the message. One""s private key, on the other hand, is kept secret, known only to the user.
Keys are typically stored on xe2x80x9ckeyrings.xe2x80x9d Public keys, including a user""s own as well as those of colleagues"", are stored in a xe2x80x9cpublic keyringxe2x80x9d file. A user""s private key is, in a similar fashion, stored in a xe2x80x9cprivate keyringxe2x80x9d file. Each key pair has a User ID (such as the owner""s name and e-mail address) so that the user and the user""s colleagues can identify the owners of keys. Each private key also has a passphrase, or verbose password, that protects it. No one but a message""s intended recipient can decrypt the message, not even the person who originally encrypted the message, because no one else has access to the private key necessary for decrypting the encrypted message.
Since public key cryptography provides privacy without the need for the same kind of secure channels that conventional secret key encryption requires, it is commonly employed to send secured messages and other documents from one individual to another across a network or other communication channel, including the Internet. An example of its use in a commercial product today includes PGP(trademark), available from Pretty Good Privacy, Inc. of Santa Clara, Calif.
Keys are also used to digitally sign a message or file and, in a complementary manner, to verify a digital signature. These xe2x80x9cdigital signaturesxe2x80x9d allow authentication of messages. When a user signs a message, a cryptographic program uses that user""s own private key to create a digital signature that is unique to both the contents of the message and the user""s private key. Any recipient can employ the user""s public key to authenticate the signature. Since the signer, alone, possesses the private key that created that signature, authentication of a signature confirms that the message was actually sent by the signer, and that the message has not been subsequently altered by anyone else. Forgery of a signed message is computationally infeasible.
By way of summary, FIG. 1B illustrates the functions for which public and private keys are used when sending and receiving messages. When keys are used to secure files stored on a user""s own computer or local network server, the user is both the xe2x80x9csenderxe2x80x9d (the person who saves the file) and the xe2x80x9crecipientxe2x80x9d (the person who opens the file).
Cryptographic systems, including ones implementing public key cryptography, are described in the technical, trade, and patent literature. For a general description, see e.g., Schneier, Bruce, Applied Cryptography, Second Edition, John Wiley and Sons, Inc., 1996. For a description focusing on the PGP(trademark) implementation of public key cryptography, see e.g., Garfinkel, Simon, PGP: Pretty Good Privacy, O""Reilly and Associates, Inc., 1995. The disclosures of each of the foregoing are hereby incorporated by reference.
Despite the benefits of public key cryptographic products, a particular problem arises in their everyday use, however. Oftentimes there exists a need for locating and sharing public cryptographic keys with peers. This is typically done through a Public Key Infrastructure, using publicly-available public key servers. The problem which arises stems from the fact that such key servers are not tailored towards corporate environments. In particular, public key servers essentially function as xe2x80x9cdumbxe2x80x9d repositories for keys, with the result that such servers often store many bogus keys and unnecessarily-large keys. This leads to server bloat, confusion by novice users, and inefficient use of system resources (e.g., bandwidth, CPU performance, and storage requirements).
In corporate environments, in contrast, customers (i.e., the users) demand control over keys they maintain. To date, however, the only solution available for imposing a crypto policy is a manual one: the system administrator must manually inspect and authenticate keys which have been submitted for storage on a company""s key server(s). For instance, the system administrator could delete undesirable keys, User IDs, and signatures, or could be the only one allowed to add keys to the key server""s database. Such a labor-intensive approach, however, places too great of a burden on the system administrator and is, thus, impractical for all but the smallest of companies. All told, there exists a need for a cryptosystem having methodology for automating the task of creating and enforcing a crypto policy at the company""s key servers. The present invention fulfills this and other needs.
A cryptosystem constructed in accordance with the present invention comprises at least one client (software) running at a workstation, terminal, desktop PC, or the like, which is connected over a network (e.g., 10/100 Base T/Ethernet) to back-end server software running on a server computer. The client software includes client cryptosystem software (e.g., PGP for Personal Privacy, Version 5.5) for providing encryption of messages (e.g., e-mail, binary files, text (ASCII) files, or the like) for supporting secured communication between a sender and a recipient.
The cryptosystem includes at the server side a Certificate (Key) Server of the present invention for storing and maintaining certificate or key information in a certificate database. The Certificate Server allows clients to submit and retrieve keys from a database based on a set of policy constraints which are set for one""s particular site (e.g., company). The Certificate Server, which is designed to run on a network operating system (e.g., Windows NT), employs Lightweight Directory Access Protocol (described below) for providing a standardized method of managing the submission and retrieval of certificates that are stored in the centralized database. In the certificate database itself, all of the necessary fields are defined and records are inserted automatically for the database during the installation process. Access to the Certificate Server is maintained by a Certificate Policy Agent, which makes sure that the policy is enforced for a given site based on the information supplied during the configuration. The configuration settings are stored in a configuration (xe2x80x9cconfigxe2x80x9d) file which determines the criteria upon which certificate submissions are either accepted or rejected by the server and how certificates can be retrieved by various clients.
During operation, the Certificate Server responds to client requests to add, search for, and retrieve certificates based on the LDAP (Lightweight Directory Access Protocol) or HTTP (Hypertext Transport Protocol) protocols. The server accepts or rejects certificates based on configurable parameters enforced by the Certificate Policy Agent. The server then accepts queries and requests for certificates from users depending on the level of access they have been granted. When a certificate is submitted to the server, the Certificate Policy Agent checks to see if it meets the criteria for a given site based on the settings specified during the configuration. Exemplary types of checks that the Certificate Policy Agent can enforce include:
(1) Checks to see if the key has been signed by the appropriate entities. The system administrator (i.e., user with administrator privileges) specifies the required signatures during the configuration.
(2) Checks to see if the signatures or User IDs associated with a key are approved for submission. The administrator specifies the allowable signatures during the configuration, including specifying the option of stripping off all unauthorized signatures or User IDs from the key before it is stored on the server.
If the submission criteria established during the configuration are met, the key is accepted by the server. If the key being submitted does not pass the policy requirements, it is rejected and a copy is placed in a xe2x80x9cpending bucketxe2x80x9d where the key can subsequently be examined by the administrator to determine if the key should be allowed on the server.
Once a key is placed on the PGP Certificate Server, it can be retrieved by a client (e.g., PGP users) for the purposes of encrypting data and verifying digital signatures. Clients access keys on the server using standard LDAP search and retrieval functions based on the attributes associated with the keys. Exemplary attributes which one can search for keys include:
e-mail address
User name (both first and last names)
Key IDs
PGP key type, size, revocation status
Creation and expiration dates
The system administrator is provided with the same client interface to access keys, except that he or she will have a higher level of authority for adding, disabling and even deleting keys from the server.